The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention teaches methods, apparatus and data structures for managing collections of related objects.
Object oriented programming methodologies have received increasing attention over the past several years in response to the increasing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques that emphasize procedural models and xe2x80x9clinearxe2x80x9d code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are xe2x80x9cbrittlexe2x80x9d. That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object""s interface. Hence changes to the data and or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object""s code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of xe2x80x9ctried and truexe2x80x9d objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
However, the full promise of object oriented methodologies, especially the advantages afforded by their modularity, have yet to be achieved. A basic goal of modular systems is to provide efficient utilization of resources, yet, due to the modularity of objects, there exists an inherent potential for redundant resources and overlap in functionality. As a first example, imagine a scenario wherein two text objects (e.g. word processing documents) contain similar or identical data such as text formatting information or portions of the actual text. In this first commonplace example there is an inherent redundancy as separate objects contain identical portions of data.
In order to present additional example of the disadvantages of current distributed object operating environments, some further background discussion will now be presented. In general, distributed objects are resident in computer processes executing on computer systems. As is well known to those skilled in the art, computer processes provide a common framework under which computer systems function. By way of analogy, a computer process may be thought of as a domain within a computer system.
In actuality, a computer process typically includes an address space (i.e. a portion of memory allocated to only the process), a set of file descriptors, a process identification number, and one or more threads of execution (often referred to as threads). As is familiar to those skilled in the art, a single thread of execution is essentially a sequential flow of the point of execution through a process. Multi-threaded systems allow for multiple threads to run concurrently in a single process. For a more detailed description of threads, multithreaded processes, and principles of concurrency, please see xe2x80x9cConcurrency Within DOE Object Implementationsxe2x80x9d by Dr. Robert Hagmann, Version 0.91, May 27, 1993, published by SunSoft and incorporated herein by reference in its entirety. For another detailed description, please see xe2x80x9cMultithreaded Programming Guidexe2x80x9d published 1994 by SunSoft and incorporated herein by reference in its entirety.
As a direct result of the framework of computer processes, all entities residing under a single process will share resources (i.e. memory and files). Thus multiple target objects residing in a single process will have efficient communication with one another.
Furthermore, data can be loaded into memory that all objects residing in the single process will have access to. However, programmers may have other motivations (beyond efficient transport and data sharing) which negate the advantages gained by having many objects in a single process. For instance, different objects will have different objectives and may rely on different assumptions about the process. Programmers must be able to keep objects within separate processes, thereby preventing conflict between and maintaining the integrity of objects within separate processes. As a case in point, an object in a first server process may go into an error condition and begin chaotically writing within its server process memory. Nevertheless, objects running in separate server processes will remain intact since these processes have their own memory, files, and flow control. These motivations generate a need for orderly, multi-process distributed object operating environments. Ideally there should be a mechanism by which programmers can determine the process within which their specific object will reside.
As is well known those skilled in the art, objects must be activated within their host process prior to serving clients. In addition, a first server object responding to the call of a first client will often in turn call a second server object which may in turn call a third server object (and so on). Thus multiple objects may be activated in response to a single call. If it is known a priori that this is the case, a mechanism which enabled multiple object activations in response to a single call may decrease the overhead associated with multiple single instance object activations. However, in current distributed object frameworks, there is no such mechanism.
While some of the abovementioned inefficiency could be eliminated within existing frameworks, the optimization of resources within current distributed systems often comes only at the expense of great programming effort. This is, in effect, antithetical to other goals of distributed object systems. Efforts to further extend the advantages of object oriented programming techniques must be directed towards improving efficiency in the utilization of all resources, including memory, processing power, and network bandwidth. What is needed is a straight forward framework in which the potential for overlap, redundancy, and unnecessary overhead within distributed objects can be easily eliminated. This will require a distributed object having a structure which will allow for a different, more efficient utilization of resources, including the capability to associate collections of objects based upon the resources which these objects share. Moreover, effective methods for managing these collections of objects will be required.
To achieve the foregoing and other objectives and in accordance with the purpose of the present invention, methods, apparatus and data structures for managing collections of objects are described. In one aspect of the invention, an object that is intended for use in a distributed object operating environment has a structure including a group designation, a coactivation designation and a co-process designation. The group designation is arranged to identify a group to which the object belongs. The group is defined as a collection of objects which share a common persistent state. The co-activation designation is arranged to identify a co-activation set to which the object belongs. The co-activation set is a collection of objects which are to be activated at the same time. The co-process designation is arranged to identify a co-process set to which the object belongs. The co-process set is a collection of objects which are to be activated within a single process. Various embodiments and a variety of methods of utilizing one or more of these designations to facilitate efficient operation of a distributed computing system are also described.
In some applications, a particular object may be conceptually divided into a plurality of sub-objects, with each sub-object having its own portion of persistent memory. In this embodiment, the particular object may only be invoked as a whole, but the object is provided with a mechanism for accessing the selected sub-object in response to a call from a client that invokes the object and identifies the sub-object in a sub-object field of an object reference that refers to the object.
In a separate aspect of the invention, objects termed object references may be provided that are arranged to permit the identification of the location of an associated object. In this aspect, the object reference includes a host identifier indicative of the host computer system on which the associated object is stored. The object reference also includes an object identifier that may be used by the host computer system to locate the object thereon. Additionally, the object reference includes a sub-object field that may be used to identify sub-objects within the associated object. In one preferred embodiment, the sub-object field is in the range of 1-32 bytes. In one specific embodiment, the sub-object field is 16 bytes.
In other aspects of the invention various methods of managing collections of objects during the invocation of a particular server object (also called a target object) in a computing system that utilizes a distributed object operating environment having an object request broker are described. In one method aspect, when a client seeks to invoke a target object located on a separate computer, a determination is made as to whether a connection already exists between a client and the server. If there is not an existing connection, a determination made as to whether the co-process to which the target object belongs is active. If so, the server""s active co-process is identified as the proper location to establish a connection. If not, the server""s co-process is activated and reported as the proper location to establish a connection.
In another method aspect a determination is made as to whether the target object is part of a group that shares a persistent state. If such a group exists and is inactive a group activation function for the target object""s group is called. In one embodiment a check is made to determine whether the target object""s group has been registered. If it has not been registered it is assumed that the target object is not part of a group and that there is no need to call the group activation function. If the target object is part of a group, then a check is made to determine whether the target object""s group is in a group registration table. If so, the object is already active, if not the group may be activated. The checking steps may be reversed or combined in alternative embodiments.
In yet another method aspect, a determination is made as to whether the target object is part of a co-activation set of objects that are to be activated at the same time. If the target object is part of such a co-activation set and the co-activation set is inactive, then all of the objects in the co-activation set are activated together. In one embodiment, a check is made to determine whether the target object""s co-activation set is identified in a co-activation table. If so, it is determined that the target object is already active and that there is no need to reactivate the target object or any of the other objects in the target object""s co-activation set. If not, the objects in the co-activation set are all activated at the same time.